Chapitre 7. Des exemples de mises en oeuvre, ailleurs

D’autres organisations statistiques publiques ont opéré les même types de mutations que celles qui nous préoccupent dans ce document. Parce qu’elles opèrent à ciel ouvert dans des forges publiques et communiquent via leur blog ou en conférences, il est aisé de contacter les auteurs de telles initiatives. Des interviews ont donc été conduites avec deux d’entre elles selon la grille d’entretien transmise en amont :

  • Are you or your institution concerned by a reproducible workflow ?
  • Would you say the workflow is reproducible in your institution ?
  • How and where is it reproducible ?
  • How and where is it not reproducible ?
  • In your opinion what are the essential ingredients and tools (R related or not) to set up a reproducible workflow ?
  • What has been done so far ? What remains to be done ?
  • Would you like to share the costs and ROI of such investments ?

7.1 Dissection du cas UK GOV

Le cas UK GOV est particulier dans la mesure où c’est la première organisation de statistiques publique à avoir communiqué sur la mise en place de sa démarche de publication reproductible, et ce dès 2017 avec cet article de blog par Matt Upson. Ce dernier s’étant depuis éloigné du projet pour d’autres fonctions, une interview d’une heure a été réalisée le 7 janvier avec Alexander Newton et Martin Ralphs. Les lignes qui suivent sont une synthèse de cet appel et de la documentation mise à disposition.

Au commencement du RAP, fin 2016, était une publication du Department for Digital, Culture, Media & Sport (DCMS) : le statistical first release, un bulletin statistique annuel sur la contribution des secteurs DCMS à l’économie britannique (valeur ajoutée, imports/exports, emplois et nombre d’entreprises du secteur).

Traditionnellement, comme pour d’autres publications, les données étaient stockées dans une base de données. Grâce à un logiciel statistique propriétaire, les données étaient extraites, manipulées et agrégées. Ces traitements étaient exportés dans des feuilles de calculs. Les tableaux et graphiques réalisés dans le tableur Excel étaient ensuite copiés-collés dans un traitement de texte avant de poursuivre un chemin de validation/relecture avant publication sur le site gov.uk.

L’approche utilisée pour construire ce bulletin est décrite comme “semi-manuelle”, elle est de ce fait jugée risquée et l’objectif est de la sécuriser en l’automatisant tout en maintenant sa qualité. S’inspirant de la recherche reproductible, des méthodes et techniques de l’ingénierie logicielle ainsi que de la mouvance DevOps, les équipes du GDS en appui au DCMS mettent sur pied le RAP, reproducible analytical pipeline : chaque parution du bulletin fait l’objet d’un projet dont le capital code est documenté, versionné, packagé, testé et intégré. Même si l’approche décrite est présentée comme agnostique, cette première expérimentation s’est faite avec des vignettes dans des packages R.

Les motivations principales initiales de la mise ne place de la démarche RAP étaient la réduction des risques et non des coûts. Et parce que le turnover faisait partie des facteurs de risques identifiés, la mise en oeuvre de la reproductibilité s’est semble t’il d’abord faite par la documentation (par programmation lettrée dans RMarkdown) plutôt que par le versionnage. Une autre motivation étant la transparence et l’ouverture sur la machinerie programmatique executée, les interviewés considèrent donc à ce titre git comme l’équipement minimum dont doit disposer une forge logicielle.

La réduction des temps de production pour une qualité équivalente a eu pour effet secondaire de permettre aux analystes de passer plus de temps sur les analyses et la réduction des coûts a été vu comme un “bonus” supplémentaire. Une autre partie du temps dégagé à servi à documenter et communiquer sur la démarche - sur le site gov.uk d’abord, puis en conférences internationales. Depuis, un MOOC (6500 participants à date), un livre, un site web ainsi qu’ un répertoire de “RAP champions” ont vu le jour. Le tout versionné et disponible dans la forge publique du gouvernement britannique. Rendre les produits du RAP publics aide à l’adoption et la promotion, parce que “c’est bien la meilleure preuve que c’est reproductible”.

Mettre en place ces démarches là prend du temps, nécessite des moyens et de la conduite du changement. Il ne s’agit pas seulement de construire de nouveaux outils et d’en équiper les responsables d’équipes pour voir la magie opérer mais d’accompagner une montée en compétences à grande échelle. La recommandation des personnes interviewées est de commencer sur un petit projet qui ne soit pas trop critique (“start small”) pour faire adhérer les sceptiques, de s’appuyer sur un réseau décentralisé d’acteurs convaincus qui adhèrent aussi à l’idée pour en disséminer les retombées. Ils alertent également sur les moyens à mettre en oeuvre pour opérer ce changement de paradigme : formation, mise en place de réseaux d’experts et de programmes d’accélération mentorés… Se pose alors la question du coût de ces opérations. En 2017, à la suite des premières expérimentations conduites également dans deux autres départments de production de statistiques officielles du Royaume-Uni, une étude de cas reporte une économie annuelle moyenne par publication statistique officielle à 8 800 livres sterling en 2 ans, incluant la montée en compétences. Et c’est là que le bât peut blesser : embarquer des managers dans la démarche est parfois difficile parce que malgré les bénéfices avérés, les responsables sont eux aussi contraints de “mettre les mains dans le cambouis”, au moins pendant un temps.

Les interviewés ont néanmoins évoqué un moyen motivant et fédérant : la charte graphique. En effet, donner la possibilité de se projeter dans le produit fini, sous forme de Markdown ou d’application Shiny avec une esthétique qui a de l’allure est très convaincant pour bon nombre de récalcitrants.

C’est d’ailleurs un des chantiers qu’il reste à mener car s’il existe un package qui traite des rendus statiques en R (type page HTML), il ne tient pas compte des exigences d’accessibilité attendues pour le web et exclut les personnes concernées par certains handicaps. L’autre axe de progrès identifié par les interviewés est l’harmonisation des pipelines.

7.2 Dissection du cas du Bureau Central de la Statistique néerlandaise

Pour rédiger ce cas d’études, c’est une interview de Mark Van der Loo, méthodologiste au Centraal Bureau voor de Statistiek (CBS) qui a été réalisée. Il est connu de l’autrice pour avoir rédigé plusieurs packages présentés en congrès qui ont trait au nettoyage statistique des données (Jonge and Loo (2018)). Le CBS est un des précurseurs, avec l’Autriche (7.3), de l’adoption de R dans sa palette d’outils. C’est un outil approuvé pour la production de statistiques officielles depuis 2010 dans cette institution. La raison en est que à ce moment là, il n’y a pas pas un mais une myriade d’outils disponibles pour répondre à une variété de besoins (Matlab, Stata, Ox, Splus, des développements maison comme Blaise et Bascula…). L’outil privilégié en production est alors SPSS. Sans parler de migration, R devient alors le langage officiel de programmation et un projet avec une organisation dédiée voient le jour. De tels montages sont importants pour en quelque sorte “cautionner” une démarche qui mobilisent les équipes informatiques pour installer R sur les postes selon une procédure maison, mais aussi un lot de packages du CRAN sélectionnés et un éditeur (qui n’est pas RStudio à l’époque). L’usage dit “desktop” est encore privilégié et l’usage de ressources serveur réservé à des travaux nécessitant de la mémoire et/ou de la puissance de calcul. Les mises à jour de R se font une fois par an, sur les postes en local : plusieurs versions de R se cotoient et les utilisateurs peuvent choisir dans quelle version ils executent leur programmes (R 2.15 est encore en usage en production pour certains programmes). Les programmes sont versionnés sur Git, outil sur lequel les agents sont formés depuis 2014.

Quand RStudio fait son entrée sur l’offre d’environnement de développement intégré pour R, il remplace rapidement l’éditeur existant (Notepad++).On pourrait imaginer que travailler en projets dans RStudio est le premier pas vers la reproductibilité, mais il est plutôt mentionné que c’est la structuration des bases de données et leur couplage avec R qui faisait plutôt défaut.

S’il y eu par le passé une documentation importante sur la qualité pour, entre autres, assurer la reproductibilité, elle n’était pas ou peu utilisée car vraisemblablement trop technique. Depuis, les “consignes” tiennent en trois instructions avec une obligation de fin et non de moyens :

  • le programme doit fonctionner sur le prochain millésime de données

  • le programme doit être versionné

  • quelqu’un qui ne connaît pas le programme doit pouvoir le comprendre et l’executer

Laconique, n’est-ce pas ? C’est à se demander pourquoi se donner la peine de rédiger tout un laïus sur la conduite du changement, les bonnes pratiques ou encore une documentation exhaustive s’il suffisait pour que la magie opère de passer quelques consignes. Mais d’une part les lignes de conduites recouvrent beaucoup sinon tous les principes évoqués tout au long de ce rapport de présentation et d’autre part, ce serait omettre une dimension importante de la manière dont cet institut s’est saisi d’une facette de la reproductibilité. En effet, ces 5 dernières années, un changement significatif dans la politique de recrutement de l’institut a visé à recruter des personnes avec des niveaux de formation plus élevés et plus au coeur des problématiques d’ingéniérie logicielle et un vrai travail de fond a été conduit pour rendre le métier attractif. A budget constant (voire plus faible), moins d’agents produisent plus de publications en s’appuyant naturellement sur les outils de la forge.

Comme les équipes de la statistique publique au Royaume-Uni, Mark Van der Loo souligne - avec toutefois moins de véhémence- l’importance d’outiller les utilisateurs pour l’esthétique des rendus. Ces outils ont été développés assez précocément dans l’institutionalisation de l’outillage statistique.

7.3 Observation du cas de la Statistique Autrichienne

Contrairement aux cas ci-dessus, l’étude de cas de la statistique autrichienne (STAT) n’a pas fait l’objet d’une interview auprès d’acteurs impliqués et visibles dans la communauté R internationale. C’est la lecture suggérée de Kowarik and Loo (2018) suite à l’interview de Mark Van Der Loo qui a motivé cet ajout.

En Autriche, R était utilisé de façon non officielle depuis 2004. L’outil préconisé et utilisé en production était alors SAS. La mise en production “autorisée” s’est faite comme souvent observée par ailleurs dans le privé ou dans le public : une utilisation officieuse, à peine tolérée par le département informatique, diffuse doucement mais sûrement parce que les fonctionnalités répondent de façon optimale aux besoins utilisateurs. Se constitue alors un noyau suffisamment dur pour qu’il devienne un caillou dans la chaussure de l’institution et que la question soit adressée. Cette “approbation” se fait en 2013, assortie d’un parcours de formation, d’une documentation de type Wiki (qui, à l’instar de CBD sera peu plébiscitée), de groupes d’utilisateurs, d’un système de support utilisateur et surtout d’une pratique intensifiée par une population désormais plus large. L’infrastructure choisie et en vigueur en 2018 reposait sur une installation centralisée de RStudio server pro (pour ses propriétés multi-sessions), une liste de packages pré-installés et la possibilité laissée à l’utilisateur d’installer pour ses besoins des packages particuliers. Le suivi de version du capital code se fait avec SVN. Les mises à jour étaient bisannuelles et en coopération avec les utilisateurs. Comme CBD, STAT publie des packages open source et écrit des packages internes pour ses propres besoins mais il n’est pas mentionné explicitement que le package soit le vecteur privilégié de la reproductibilité pour les projets conduits en interne. La politique de mise à jour bisannuelle au rythme des versions de R de façon centralisée sans maintien de versions antérieure semble être la “voiture-balai” qui garantisse la reproductibilité des chaînes de production à l’échelle du semestre.

References

Jonge, Edwin de, and Mark van der Loo. 2018. Statistical Data Cleaning with Applications in R. John Wiley & Sons, Ltd. https://doi.org/10.1002/9781118897126.

Kowarik, Alexander, and Mark van der Loo. 2018. “Using R in the Statistical Office: The Experience of Statistics Netherlands and Statistics Austria.” The Romanian Statistical Review 66: 15–29.